Two blockers the earlier rework introduced:

1. The custom_target output was named 'pandas-vendored.cdx.json', but
   the Validate SBOM CI step in .github/workflows/wheels.yml looks for
   '*/sboms/pandas.cdx.json'. Rename the generator output to match —
   one canonical location for the vendored-code SBOM.

2. Dropping the custom repair-wheel-command override from the
   [*pyodide*] cibuildwheel override accidentally took the
   `repair-wheel-command = ""` line upstream had for Pyodide with it.
   Without that empty override, cibuildwheel falls back to its Linux
   default (auditwheel), which cannot repair emscripten wheels. Restore
   the empty override with a comment explaining why.

Five review-round-two findings, fixed together because they all touch
the SBOM pipeline:

- Restore repair-wheel-command = "delvewheel repair -w {dest_dir}
  {wheel}" under [tool.cibuildwheel.windows]. The rework dropped the
  custom script override without restoring the upstream default, so
  DLL-dependent Windows wheels were going un-bundled.
- Correct the ultrajson license expression in LICENSES/vendored.toml
  from "BSD-3-Clause" to "BSD-3-Clause AND TCL". The vendored ujson
  code carries TCL-licensed material from its double-to-ascii
  routine, as already noted in pyproject.toml's license-files list
  and LICENSES/ULTRAJSON_LICENSE.
- Make the generated SBOM reproducible: honour SOURCE_DATE_EPOCH for
  the metadata timestamp (matching meson-python's wheel timestamp
  convention), and derive the serialNumber deterministically from a
  SHA-256 of the manifest bytes + pandas version rather than uuid4().
  Same vendored.toml + same version now yields byte-identical SBOM
  output across builds.
- Add a bom-ref to metadata.component and reuse that exact value in
  dependencies[0].ref. CycloneDX dependency-graph consumers expect
  dependencies[].ref to resolve to a bom-ref in the BOM.
- Restore LICENSES/PYUPGRADE_LICENSE and its pyproject license-files
  entry, plus a pyupgrade component in LICENSES/vendored.toml. The
  earlier deletion was premature -- pyupgrade-derived code still
  lives in scripts/validate_unwanted_patterns.py, so the license
  file needs to ship alongside it. Audit and removal of that code
  is a separate exercise.

Earlier iteration of this PR required a new meson helper
(python.dist_info_install_dir()) that would have landed in meson 1.12.0.
Per reviewer feedback on the meson side, that helper is being dropped
in favour of a meson-python-only mechanism: meson-python now detects
files staged under {py_purelib}/<name>-<version>.dist-info/... in the
install plan and reroutes them into the wheel's own .dist-info/.

Pandas-side changes:

- meson.build: compute the distinfo directory locally from
  meson.project_name() / meson.project_version() and install the SBOM
  custom_target output to py.get_install_dir() / distinfo / 'sboms'.
- pyproject.toml: revert the meson>=1.12.0 pin; works with any meson
  version pandas already supports.

No new upstream meson dependency. Still requires meson-python >= 0.20.0
for the dist-info prefix detection.

Record the new SBOM shipping at
<distname>-<version>.dist-info/sboms/pandas.cdx.json for pandas 3.1.0.
Generated at build time from LICENSES/vendored.toml.

The original entry was 45 words; pandas whatsnew bullets are typically
one short sentence (~20 words). Compact to fit.

This is a scaffold commit so CI can resolve the build dependency
against mesonbuild/meson-python#843 while that PR is under review.

The pandas SBOM routing relies on path-prefix detection added in that
meson-python branch; once it lands in a released meson-python (0.20.0
or later), this commit should be dropped and the
"meson-python>=0.20.0,<1" pin restored.

NOT FOR MERGE.